Ask most plant IT managers what their recovery time objective is for the MES environment, and they’ll give you a number. Ask them when they last tested it — a full restore, from cold storage, of the historian, the MES database, the engineering workstation images, and a representative PLC — and the room usually goes quiet. The number in the DR document is real. The confidence behind it is not.
That gap used to be a paperwork problem. It’s becoming a business problem. Cyber insurers writing manufacturing risk are asking pointed questions about OT-specific recovery testing, not just whether you have a DR plan. Customer security questionnaires, particularly from automotive and aerospace primes, are starting to reference IEC 62443-2-1’s requirements around incident response and business continuity management directly. And manufacturing continues to sit at or near the top of every major ransomware incident tracker. If you’re still running a plan that’s an IT disaster recovery template with “OT” find-and-replaced into it, you’re carrying risk you haven’t priced.
Why the IT DR plan doesn’t transfer
IT recovery assumes a world of virtual machines, snapshotting, and infrastructure that’s largely homogeneous. OT is none of that. You’ve got PLC firmware and ladder logic living on hardware that might be a decade old, HMI configurations tied to specific software versions, historian tag databases with years of contextual metadata, and MES recipe and routing data that has to reconcile exactly with what’s running on the floor — not approximately, exactly, or you get scrap, mis-labeled product, or a safety incident.
The other difference is sequencing. In IT, you generally restore whatever’s most business-critical first — email, ERP, file shares. In OT, the order is dictated by physics and safety, not business priority. Bringing an MES back online before the safety instrumented systems and utilities are verified is a good way to have a fully digitized record of a plant that isn’t actually safe to run.
What actually needs to be in the backup set
A realistic OT backup inventory looks different from what most sites have documented, and it’s worth checking yours against this list:
- PLC and safety controller projects — the actual engineering source files (not just compiled logic), version-controlled, including safety PLC configurations separately from process control logic.
- HMI and SCADA configurations — screens, alarm setpoints, tag databases, and the runtime licensing artifacts you’ll need to reactivate them.
- Historian data and tag structure — the historical process data has compliance and quality value, but the tag configuration itself is what lets MES and SCADA reconnect coherently after a rebuild.
- MES database and recipe/routing masters — including the interface configurations (OPC UA server settings, MQTT broker configs, ISA-95 B2MML mappings) that tie MES to the control layer. These integration configs are routinely forgotten and are murder to rebuild from memory.
- Firmware images and drive/robot parameter files — for anything with a proprietary configuration that can’t be re-entered by hand in a reasonable time.
- Network configs for the OT DMZ — firewall rules, VLAN assignments, and the segmentation architecture itself, per the ISA-95/Purdue-style layering most plants claim to follow.
Notice what’s on that list that almost never makes it into an IT-authored DR plan: firmware images, safety controller configs, and the interface mappings between MES and the control layer. Those are usually the long poles in an actual recovery, and they’re the pieces IT teams don’t know exist because they live in engineering’s world, not IT’s.
Where the backups live matters as much as what’s in them
Ransomware operators target backups deliberately now — that’s well established industry practice on the attacker side, not speculation. If your OT backups are reachable from the same domain credentials or the same network path as production, they’re not a recovery asset, they’re a second target. Immutable, offline, or air-gapped storage for OT backups should sit logically outside the OT DMZ, with its own access control and its own credentials that don’t trace back to the same Active Directory forest running the plant floor. Some sites keep a physically separate backup domain for OT specifically so that a domain-wide compromise doesn’t also take out the restore path. Write-once storage, whether that’s an immutable object store or actual offline media rotation, isn’t a nice-to-have anymore — it’s close to a baseline expectation in underwriting conversations.
The recovery sequence: safety and utilities first, MES last
A tested runbook sequences recovery roughly like this:
- Safety instrumented systems and life-safety infrastructure — verified and validated before anything else comes back online, using documented safety configurations, not assumptions.
- Utilities and base building systems — power, compressed air, HVAC where relevant to process, water treatment where applicable.
- Core process control — PLCs, drives, and the basic control loops needed to run equipment safely, brought up and manually verified against known-good setpoints.
- SCADA/HMI layer — restored and reconnected to the now-verified control layer.
- Historian — reconnected once tag structures are confirmed to match the restored control configuration.
- MES — restored last, and only reconnected to the floor once its interface configurations have been checked against the actual as-restored control system, not the pre-incident assumption of what that system looked like.
MES going last isn’t a slight against MES — it’s that MES is only useful, and only safe, once everything underneath it is verified. An MES happily dispatching work orders to a line that isn’t actually configured the way MES thinks it is will generate confident, wrong data all day long.
Tabletop first, then a live drill that doesn’t touch production
You don’t need to ransomware your own plant to test this. Start with a tabletop exercise: walk the incident response team, including someone from engineering and someone from the process safety side, through the sequence above using the actual documented runbook, and time each step on paper. This surfaces the obvious gaps — nobody knows where the firmware images are, the backup credentials are the same as production, three people who’d need to be in the room don’t know the plan exists.
The next step is a live restore, done on isolated hardware or in a test cell that has no path back to production — a spare PLC, a virtualized MES test instance, a segregated historian sandbox. Time the actual restore of each component from your backup media. This is where fictional RTOs die. A plan that says four hours often turns out to take a day and a half once someone accounts for locating the right firmware version, re-licensing SCADA software, and manually re-verifying safety setpoints before anything is allowed to run. That’s not a failure of the drill — that’s the drill working. The whole point is finding that out on a Tuesday afternoon, not during an actual incident with a ransom note on the HMI.
What this means for the paperwork you’re signing
IEC 62443-2-1 frames business continuity and incident response as part of an ongoing security management system, not a document you write once and file. Cyber insurers underwriting manufacturing risk are increasingly asking for evidence of testing, not just a policy citation. If your last “test” was a tabletop conversation and your RTO figure was inherited from an IT template, that’s a gap worth closing before someone else finds it for you — an insurer during a claims dispute, an auditor during a customer assessment, or an attacker during the incident itself.
The plants that get this right treat OT recovery testing the way they treat calibration or preventive maintenance: scheduled, documented, and boring. The plants that get it wrong find out their RTO was fiction at the worst possible time, with production down and a clock the insurer is also watching.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
